This extension for Eudora bursts various non-MIME digests (Eudora already handles MIME digests). That is, it takes a message digest as input and produces a new mailbox as output which will contain one message for each component of the digest. It can also be used to extract a forwarded message if (and only if) the full rfc934 spec was followed in the forwarding.
To install, place it in the "Eudora Stuff" folder inside the Eudora application folder. Eudora will install this extension the next time it is launched. You can see which message service extensions you have installed by selecting "About Extended Message Services…" in the Apple menu.
To burst an open message, select the "Extended Services" menu item in the Edit menu, and then select one of the translation services described below from the submenu. You'll be prompted for a file destination for the burst digest. Any destination will do, it doesn't have to go into your Eudora Folder.
The default behavior is to create a new mailbox for each bursting. If you want to append to an existing mailbox instead, enter its name and click the Append button in the subsequent dialog. If you hit the Replace button, the old contents will be lost -- so be careful! Upon completion, the destination mailbox should be opened in Eudora. The original message will be left empty; if you want to retain the original contents, close the window and choose "Discard" when Eudora asks what you want to do.
The burst services are best run with either no text selected, in which case the body of the message, but not the headers, will be processed; or with everything selected (eg by typing cmd-A), in which the case the full message, including its headers, will be processed.
Burst provides four translation services: Burst rfc1153, Burst rfc934, Burst generic and Burst other. These translation services are described in detail below. Generally speaking, the first two follow official rfcs and are unambiguously parsable, while the second two are not unambiguously parsable. This means that the rfc bursters should be used when you believe you have a digest which follows the corresponding rfc, because the bursting algorithm is by definition more reliable. If you're unclear whether a particular digest is rfc934, rfc1153, or neither, drop me a line, and I'll send you a much more thorough description, including rfcs themselves.
Burst rfc934:
This is appropriate for true rfc934 digests (rfc934 is the document which describes the standard pre-MIME digest format) and is best run only on the body, in other words, with nothing selected. This burster follows the rfc standard completely and is only appropriate for digests which likewise follow the standard. It can also be used to extract a forwarded message if true rfc934 was used in the forwarding. Please note that Eudora's own "Forward934" plugin does not follow the standard.
Most rfc934 digests will include a line something like the following, noting the beginning of the digest:
------- start of digest (... messages) (RFC 934 encapsulation) -------
where the "..." is a number. This is not required by the spec however. In other words, you may have a 934 digest even if it doesn't have a line like this.
Burst rfc1153:
This is appropriate for true rfc1153 digests, which includes many digests produced by listserv mailing-list managers. It's best run only on the body, in other words, with nothing selected. This burster follows the rfc standard completely and is only appropriate for digests which likewise follow the standard.
An rfc1153 digest can be recognized by the following characteristics:
1. The beginning of the digest will be marked by a line consisting of exactly 70 hypens, followed by a blank line.
2. Between messages will be a blank line, followed by a line of 30 dashes, followed by another blank line.
3. The last message is followed by a blankline, a line of 30 dashes, another blank line, a line saying "End of <whatever> digest", and a line of asterisks.
Burst generic:
This is appropriate for informal digests of the sort produced by majordomo mailing-list managers, and also some listserv implementations. Since these don't follow any unambiguous standard, Burst uses a heuristic to find message boundaries. It assumes that a message boundary is indicated by a line beginning with four dashes (or four equal signs) that contains nothing but dashes (or nothing but equal signs), followed by a line that looks more or less like a mail header. Please note that a digest may contain such a line that is not, in fact, a message separator, in which case the burst digest will contain a spurious message. That's the price of using unofficial, ambiguous digest formats rather than one of the unambiguous standards (rfc934, rfc1153 or MIME).
The initial text in the digest, before the first component, will be made into a dummy message in the destination mailbox. The headers attached to this dummy message depend on what was selected in the digest before translation. If nothing was selected, the initial message will have no headers at all, and will appear in the summary as being from "Burst". If everything was selected, the headers from the digest itself will be used instead. In either case, the rest of the new messages in the destination mailbox will contain the digest's components.
Burst other:
This is like the generic case, except that the message-boundary heuristic is a little looser. It assumes that a message boundary is indicated by a line beginning with four dashes (or four equal signs), followed by a line that looks more or less like a mail header. The rest of the boundary line, after the first four characters, is ignored. This converter will handle a slightly wider variety of digests, but, because it uses a looser heuristic, it's also slighly more likely to get confused by digests with weird stuff in them. I would suggest trying this option only if the others provide less than satisfactory results.
Some things to look out for:
1. Eudora can use quite a bit of memory to display large messages, in which case there may not be enough left to do the bursting. If this happens, you should see an error dialog saying "Out of memory". You'll need to quit Eudora, give it more memory, and start again.
2. Aborting out of a translation, with cmd-., does the wrong thing right now. At this point I'm unclear whether this is a Eudora bug or a Burst bug or a misunderstanding on my part regarding the way this is intended to work.
